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(54) Method and apparatus allowing a limited client device to use the full resources of a 
networked server 



(57) Disclosed is a thin-client system (1 0) operative 
over a communications network (16) to provide a thin- 
client device (12) with resources present at the server 
(14). The server (14) includes a communication control 
device that sends and receives messages over the net- 
work (1 6), and an operating system. Further, the server 
has access to a data base with capability to store certain 
applications executable on its operating system. Mean- 
while, the client device (1 2) includes a display, an exter- 
nal communication device for sending messages to the 
server and receiving messages from the server (14) 
overthe network, and a dedicated client schemeforcon- 
trolling the display and the external communications de- 



vice. Messages between the client device (12) and the 
server (14) conform to a control-oriented protocol that 
restricts the type of message permissible for transmis- 
sion to only those descriptive of certain preselected 
events that are necessary for execution of a dedicated 
application on the server (14). The protocol excludes 
many user actions that otherwise would be transmitted 
to the server (14) from the client device (12) according 
to conventional display-based protocols. The present in- 
vention further contemplates methods for so enabling a 
thin-client device to use server resources, and also com- 
puter-readable mediums containing software for carry- 
ing out such methods on appropriately equipped servers 
and client devices. 
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Description 

BACKGROUND OF THE INVENTION 

[0001 ] The present invention is both a method and an 
apparatus that enables a client device which has very 
limited processing capability, namely a "thin-client" de- 
vice, to access and use the full resources of a server 
over a network. In particular, the present invention re- 
lates to a method and an apparatus in which a thin-client 
device and a server communicate over the network by 
messages that represent discreet events and that ad- 
here to a control-oriented protocol in accordance with 
the invention. 

[0002] With the explosion of the Internet, a worldwide 
focus has been placed on the discipline known as net- 
work computing. The Internet has demonstrated to the 
world the immense power and opportunity presented by 
the capability of individuals in different locales to ex- 
change and view information. Simultaneously, the Inter- 
net has proven that the thin-client computing model, 
where multiple client devices access information stored 
on centralized servers, is a viable and efficient means 
of organizing a computer infrastructure. 
[0003] Concurrent with the renewed interest in net- 
work computing, computing technology continued to 
provide less expensive devices with ever increasing op- 
tions to connect with remote computing devices via a 
growing number of varied communications network in- 
frastructures. While the Internet has acted as a catalyst 
for development and improvement of the methodologies 
used to exchange, distribute and access data stored on 
distinct and remote computing machines, relatively little 
improvement has been made in the way in which appli- 
cations stored on distinct and remote computing ma- 
chines, are shared. The thin-client computing model, 
while not a new phenomenon, has been widely accept- 
ed by organizations engaged in providing access to ap- 
plications to a large number of potential users. The thin- 
client computing model has been widely embraced due 
to its lower cost of maintenance when compared with 
the alternative thick-client computing model, as well as 
ease with which a thin-client computing installation can 
be upgraded. 

[0004] However, the current normally accepted meth- 
ods of achieving thin-client access to central applica- 
tions have not evolved along with the nature and capa- 
bility of the applications being accessed. The focus of 
these older thin-client computing methodologies tradi- 
tionally has been either character-based application ac- 
cess, or thin-client computing via a network of fixed 
workstations with permanent and otherwise reliable 
connections to a wired communications network. Typi- 
cally, these conventional methodologies, and conven- 
tional architecture incorporating such methodologies, 
have adopted a display-based protocol for regulating 
data transmission between the thin-client and the server 
computer. Extending such conventional thin-client ar- 



chitecture to wireless devices immediately confronts the 
challenges of limited bandwidth. Conventional architec- 
tures have proven inefficient and ill-suited for the con- 
straints imposed by limited bandwidth in wireless com- 
5 munication. 

SUMMARY OF THE INVENTION 

[0005] The invention described herein addresses, 

10 among otherthings, the inefficiencies of a display-based 
protocol over limited bandwidth. The invention uses a 
highly efficient communication protocol that is control- 
based ratherthan display-based as conventionally used 
in thin-client architectures. This allows efficient access 

15 to server-based applications from varying client devices 
with limited capabilities and interfaces over any network 
communications infrastructure capable of delivering 
messages, complying with the control-oriented protocol 
of the present invention, between a server and a thin- 

20 client device. The present invention thus enables a thin- 
client device, having minimal software and/or a minimal 
operating system, to efficiently transmit messages com- 
pliant with the control-oriented protocol over the com- 
munications network medium, to start, control, close 

25 and otherwise use applications that have been compiled 
with controls compliant with the protocol. These appli- 
cations, dedicated to the inventive protocol, reside at or 
otherwise are accessible from one or several server 
computer(s). The server transmits user-interface de- 

30 scription data, input/output hardware control data, and 
user-interface and hardware event data to the client de- 
vice using a predefined set of messages that are in ac- 
cord with the protocol. The client device, in turn, uses 
the user-interface description data to locally construct a 

35 representative user interface. Likewise, the thin-client 
uses received input/output hardware control data to op- 
erate input/output hardware incorporated or attached to 
the client device, and/or received user-interface and 
hardware event data to perform corresponding events 

40 locally on the client device. Of course, the same pre- 
defined messages of the control-oriented protocol can 
originate from the client device and be transmitted to the 
application on the server, in response to corresponding 
user or hardware actions on the client device. 

45 [0006] The invention allows a dedicated application to 
be started, operated, closed and otherwise run by mul- 
tiple clients simultaneously. On the server, such opera- 
tion creates multiple instances of the application, direct- 
ly equivalent in numberto the number of client requests 

50 to operate any given application. Conversely, any client 
device can start, operate, close and otherwise run any 
number of applications residing on, or accessible by, 
any number of servers concurrently. The application re- 
ceives input from, and directs output to any input/output 

55 (I/O) mechanism resident on the client device. Accord- 
ing to the present invention, the application also will be 
notified of, and made to respond to events relevant to 
the client device such as a low power source condition 
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event, or an out of communication network condition 
event, in addition to other normal client device operation 
events such as the touching ('a click') of a screen ele- 
ment on the client device event, or a suspension of the 
application (on the client device) event, followed by a 
resumption of the application (on the client device) 
event. 

[0007] According to the invention, different client de- 
vices, that is client devices utilizing different operating 
systems (or minimal operating systems), and client de- 
vices of varying size, orientation, input and output capa- 
bility and/or communications network compatibility, run 
and otherwise utilize the same dedicated application or 
group of applications on either the same, or different 
servers. On the other hand, the invention provides that 
one source code of an application to be compiled or con- 
solidated to be executable or interpretable by the server, 
subsequently can be run (controlled) by such various 
different client devices. 

[0008] An important aspect of the invention is that it 
is a methodology for creating messages to allow remote 
access to the events, features and operation of comput- 
ing objects and the resources of the server, and simul- 
taneous access by the application to device-specific 
hardware and features of the client device. Interpreta- 
tion of messages will become apparent as straightfor- 
ward to those of ordinary skill in the art. Those of such 
ordinary skill will appreciate that the present invention 
could be implemented using a variety of distinct soft- 
ware languages and/or hardware control languages for 
both the client device and the application to be executed 
on the server machine. Examples of contemplated soft- 
ware languages are Java® , the C and C++ program- 
ming languages, the Object Pascal programming lan- 
guage, and other such high-level programming lan- 
guages. Examples of hardware control languages and 
mechanisms are Assembler language specific to a giv- 
en hardware device, microprocessors and micro-con- 
trollers equipped with hardware instruction sets, and 
other such low-level programming languages and hard- 
ware control mechanisms. Where the invention is car- 
ried out in this way, the client device will have the capa- 
bility to run applications concurrently on several distinct 
servers, regardless of whether the servers have differ- 
ent operating systems, or different application com- 
mand interpreters. Examples of different operating sys- 
tems contemplated for use with the present invention 
are Microsoft® Windows NT® .RTM, Hewlett Packard® 
HP-UX® .RTM, Sun Microsystems® Solaris® .RTM, 
versions of the Linux® operating system, and other such 
operating systems. 

[0009] According to the invention, the application, 
while being run from the client device, appears as if it 
were running on the client device. Preferably, the appli- 
cation appears with the display characteristics of any 
applications customarily residing on the client device, 
should the client device itself have the capability to store 
and run applications locally. It also is contemplated that 



client software, compliant with messages in the dedicat- 
ed control-oriented protocol and residing on the client 
device, can be installed and subsequently updated and/ 
or re-installed over the communications network. Pro- 

5 vided that there is an initial minimal software or other 
hardware instruction set, compliant with, at minimum, 
the subset of messages in the protocol associated with 
installation and transfer of the client software, the client 
software can be distributed to the server, and subse- 

10 quently downloaded and installed by a client device uti- 
lizing an available communications network medium. 
[0010] In accordance with the invention, a client de- 
vice requires: a display allowing the user of the client 
device to see textual and/or graphical information; an 

15 external communications interface allowing the client 
device to transmit and receive messages complying 
with the control-oriented protocol to the server over such 
communications medium; and minimal software dedi- 
cated to the protocol and capable of receiving input from 

20 the user, or input from other input devices associated 
with the client device. The client device dedicated soft- 
ware issues commands to control the display of the cli- 
ent device, and interprets and generates messages that 
conform to the control-oriented protocol. 

25 [0011] Further in accordance with the invention, an 
application dedicated to the control-based protocol of 
the invention must incorporate controls conforming to 
the protocol. The protocol is incorporated at the time the 
source code of the application is generated so that the 

30 application is capable of interpreting and providing mes- 
sages included in the control-oriented protocol. The ap- 
plication is provided with the capability to transmit and 
receive messages according to the control-oriented pro- 
tocol by a communication control device in the server. 

35 Alternatively, use can be made of adjunct software ca- 
pable of transmission and receiving of messages over 
the applicable communications medium. The applica- 
tion runs and/or otherwise issues commands to the 
server so as to accomplish tasks readily associated with 

40 software applications in use worldwide. 

[0012] Still further in accordance with the invention, 
the server computer requires: a communications control 
device capable of placing messages on the communi- 
cations medium; the capability to receive, respond to, 

45 generate and otherwise interpret and execute com- 
mands issued by the application by means of an oper- 
ating system, or otherwise. The server performs these 
functions for one instance of an application, or simulta- 
neously for multiple instances of an application. 

50 [0013] Yet further in accordance with the invention, 
the control-oriented protocol of the invention generally 
restricts data, that is, it generally restricts messages 
communicated between the thin-client and the serverto 
only events necessary for execution of the application 

55 on the server, and to other important hardware-oriented 
events. By so restricting the nature of informational mes- 
sages communicated between client and server, the in- 
ventive protocol provides for full client access to appli- 
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cations on the server, within the constraints of narrow 
bandwidth characteristic of wireless systems. In the 
case of actions by the user at the client device, the dis- 
closed control-oriented protocol permits generation of 
messages destined forthe server, from the client, to only 
those descriptive of certain, significant events. A signif- 
icant user event, for example, is interpreted or recog- 
nized by the application as indicative of the user's oper- 
ation of a certain associated application control present- 
ed at the user interface on the client device. The mes- 
sage transmitted to the server includes data necessary 
to describe this preselected event but excludes other 
data that, in a display-based protocol, also would be 
transmitted to the server because it represents other ac- 
tion taken by the user to operate the associated control. 
Such other data is excluded because it does not repre- 
sent the preselected event. 

[0014] An example used in this disclosure is defining 
a mouse "click" as a selected event, but not so defining 
mere mouse movements. In this example then, the cli- 
ent device would not transmit messages to the server 
while the user merely moved a mouse at the client de- 
vice, but would send a message as soon as the user 
"clicked on" an application control displayed on the user 
interface. At the server, receipt of the message informs 
the application that an event has occurred at the client 
device. The application interprets the event message as 
indicating that the associated displayed application con- 
trol has been operated ("clicked"), and thereafter re- 
sponds appropriately. 

[0015] Messages from the application to the client 
likewise are constrained to preselected events. In addi- 
tion, various hardware-oriented events, discussed in de- 
tail hereafter, are described by messages between the 
client and the server. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 6] Further aspects and features of the present in- 
vention will be even more apparent from the following 
detailed description and drawings, and the appended 
claims. 

[0017] In the drawings: 

Figure 1 is a block diagram of a thin-client system 
over plural possible networks in accordance with 
the present invention; 

Figure 2 illustrates an overlay of a control-oriented 
protocol in accordance with the invention on a con- 
ventional wireless protocol suitable for use in the 
system of Figure 1 ; 

Figure 3 is a detailed block diagram of a preferred 
thin-client device and an associated server compu- 
ter suitable for use in the system of Figures 1 and 2; 
Figures 4A and 4B together show a flow chart of 
operation in accordance with the present invention; 
Figure 5 is a structure chart illustrating the process 
of updating and/or installing dedicated client soft- 



ware in accordance with the invention; 
Figure 6 is an illustrative diagram of a dedicated ap- 
plication run by the system of Figure 3; 
Figure 7 is a simplified block diagram of an alterna- 
5 tive system configuration according to the present 

invention; and 

Figures 8-10 present exemplary screen displays 
with 

10 Figure 8 showing a new project for develop- 

ment of a new dedicated application in a com- 
mercially available visual development lan- 
guage, 

Figure 9 showing an exemplary new dedicated 
15 application running on the server side, and 

Figure 10 showing the application of Figure 9 
mimicked on the client side. 

DETAILED DESCRIPTION OF THE PREFERRED 
20 EMBODIMENTS 

[0018] Figure 1 shows a system providing overall sys- 
tem thin-client devices with access to the full resources 
of a server in accordance with a preferred configuration 
25 of the present invention. In Figure 1 , system 1 0 is seen 
to include multiple client-side devices 12A through 12M. 
System 10 supports many such client devices 12, and 
such devices 12 can enter and exit the system at ran- 
dom. System 1 0 provides access for any arbitrary client 
30 device 1 21 to a plurality of servers 1 4A through 1 4N on 
the so-called server-side. Servers 14A through 14N, in 
turn, are connected to each other and to the client de- 
vices over at least one network 16 which provides the 
communication medium. A second network also is 
35 shown in broken lines as it will be apparent that multiple 
networks can be incorporated in the preferred system. 
Such communication mediums could comprise tele- 
phone switching networks, ethernet networks, Wireless 
802.11 networks, Mobitex® messaging networks and 
40 the like. Because transmission between elements of 
system 10 can be carried out in a connectionless man- 
ner, in the preferred arrangement of Figure 1 , exemplary 
client-side device 121 is contemplated as a hand-held, 
wireless device. However, as apparent to those of ordi- 
45 nary skill in the art, any client-side device could, instead, 
be a desktop device with limited processing power. 
Where client device 121 is a hand-held, wireless device, 
it includes an external communication link and a (sche- 
matically-depicted) antenna 20 for connection with the 
50 network 1 6 at an available RF access point depicted as 
block 22. 

[0019] With reference now to Figure 2 also, system 
10 is shown with a block-diagrammic representation of 
a dedicated protocol for system 1 0 overlaid on any con- 
55 ventional standard wireless communication protocol. 
The wireless protocol ensures accurate RF communi- 
cation between an associated exemplary client device 
121 and likewise an exemplary server 141 over wireless 
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network 1 6. In this preferred implementation, communi- 
cation between client device 121 and server 141 is es- 
tablished with the User Datagram Protocol (UDP), along 
with a dedicated, control-oriented protocol 24 unique to 
system 10. Also in such a preferred embodiment, the 
UDP may be based upon frequency hopping or direct 
sequencing in spread-spectrum RF. The UDP does not 
require maintenance of a constant connection between 
any client device and the network, and so this base pro- 
tocol is desirable when one considers that wireless cli- 
ent devices may move into and out of range of radio con- 
nection with a wireless network 1 6 at random This situ- 
ation permits the client-side devices to be powered 
down when connection with the network is lost, thus bet- 
ter conserving batteries in the client devices. Dedicated, 
control-oriented protocol 24 will be discussed at length 
infra. 

[0020] Each client device 12A through 12M has the 
capability to transmit and receive messages over the 
communications network medium 1 6. Each server 14A 
through 1 4N likewise has the capability to transmit and 
receive messages over the medium 1 6. The contents of 
the messages transmitted between the client devices 
and the servers in system 10 are governed by the con- 
trol-oriented protocol to be discussed. Additionally, each 
server 14A through 14N has the capability to run and 
otherwise interpret what will be referred to as "dedicat- 
ed" applications 13A through 130 depicted as residing 
on the exemplary server 141. It goes without saying that 
while only server 141 is shown with residing dedicated 
applications 13A through 130, all servers 14A through 
14N of system 10 can have residing dedicated applica- 
tions, or at least access to such applications. Software 
and/or hardware on each client device, each dedicated 
application, and an optional administrative server appli- 
cation 15 all have capability to generate and interpret 
messages conforming to the preferred protocol of the 
invention. 

[0021] Due to the message-based nature of the pre- 
ferred control-oriented protocol, it will become apparent 
to those of ordinary skill in the art that multiple distinct 
applications can be run on any server 141 , from any cli- 
ent device 121, regardless of the multitasking capability 
of the client device. The only process (dedicated client) 
that need actually run on theclient device 121 istheclient 
software required to communicate with the applications 
13A - 130. This software process handles communica- 
tion with multiple applications running on one, or multi- 
ple servers, by intelligently switching between applica- 
tions under the direction of the client device user. 
[0022] Similarly, it is contemplated that any such client 
device 121 can concurrently run applications on multiple 
of servers 14A - 14N. Client device 121 concurrently 
manages messages of the control-oriented protocol 
with multiple distinct applications, and so any applica- 
tions executable on any of servers 14A - 14N that are 
accessible to the client device, through any particular 
communications medium, can be engaged by the client 



device. 

[0023] As mentioned earlier in connection with sys- 
tem 1 0 of Figure 1 , the multiple client devices 1 2A - 1 2M 
access a plurality of server computing machines 14A - 

5 14N over one or a plurality of communications network 
mediums. This many-to-many relationship is possible 
because the control-oriented message based nature of 
the protocol necessitates that communication pass only 
between the client devices to the applications (on the 

10 servers) upon the occu rrence of certain selected events 
relevant to the dedicated application or applications in 
use. 

Exemplary Client-Side and Server-Side Devices 

15 

[0024] We turn to Figure 3 for details of exemplary, 
preferred wireless, client-side device 121 and a pre- 
ferred server 1 41. Server 1 41 includes a communication 
control 100 for regulating the transmission and receipt 

20 of data over network 1 6. Internal server software and/or 
hardware shown and referred to as "dedicated" server 
104 is associated with the client devices for message 
communication therewith. Dedicated client server 104 
handles all client device requests for creating and run- 

25 ning applications specifically "dedicated" for use in ac- 
cordance with the invention. The dedicated server 104 
accesses a dedicated application data base 106, and a 
client identification and/or authorization data base 108. 
In preferred configurations, a software development 

30 toolkit (SDK) data base 112, shown in phantom lines, 
also could be provided. In any given server 141, appli- 
cation data base 1 06 stores one or more of dedicated 
applications 13A through 130 figuratively shown in Fig- 
ure 1 and made available to the plural client devices. 

35 Server 141 also has access to like data bases 106 and 
1 08 provided in other servers in system 1 0, and also can 
have access to any other remote such data base. Ap- 
plication data base 106 is complemented by the client/ 
authorization data base 1 08 which contains a list of us- 

40 ers and client devices already recognized by system 10. 
Preferably, applications stored in data base 1 06 are or- 
ganized into groups so that individual users can be as- 
signed rights in the different application groups. Access 
to applications then can be controlled by the specifica- 

45 tion of such groups. It is relatively simple to enforce a 
security policy where access to the applications in a giv- 
en group is controlled by allowing only users included 
in the group to access such applications. 
[0025] In such a preferred configuration, for each user 

50 there is account data with the user's identification, a 
password, and authorization priority stored in data base 
108. This ensures that each client-side device user 
would have access to run only those applications for 
which the user has proper authorization. It is contem- 

55 plated that all passwords would be encrypted for trans- 
mission. 

[0026] Where system 10 is configured to accommo- 
date the creation of dedicated applications, SDK data 
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base 1 1 2 is preferable. In this data base, all controls for 
creating dedicated applications can be stored. Of 
course, all such controls will be made to comply with the 
control-oriented protocol discussed infra. 
[0027] Server 141 also is shown to include an operat- 
ing system 110. The operating system 110 coordinates 
operation of all elements of server 141. Operating sys- 
tem 1 1 0, equipped with dedicated server 1 04, is provid- 
ed with the capability to receive, respond to, generate 
and interpret and execute commands issued by a ded- 
icated application, and to perform those functions simul- 
taneously for multiple instances of any such dedicated 
application. In a contemplated commercial embodi- 
ment, operating system 1 1 0 comprises a Windows NT® 
operating system. 

[0028] On the client side, a preferred client device 121 
also is seen to include an operating system 200. Oper- 
ating system 200 is contemplated as limited insofar as 
it is incapable of creating and/or executing the dedicated 
applications stored in data base 106 (on the server 
side). In the contemplated commercial embodiment 
where server-side operating system 110 comprises 
Windows NT® , the client operating system 200 could 
comprise the Windows CE® operating system for mo- 
bile devices. However, it should be understood that sys- 
tem 1 0 will provide like capability for any client operating 
system 200 including that known by the trade name 
Palm OS® , that known by the trade name EPOC, Tel- 
met, or any other like operating system used in tele- 
phone-type and other hand-held devices known to those 
of ordinary skill in the art. Although certain commercially 
available operating systems are discussed as preferred 
herein, it should be understood that the present inven- 
tion is not limited to use with any particular operating 
system, and other graphics oriented operating systems 
and associated software could be employed. 
[0029] Operating system 200 coordinates control 
among user input 202, display memory 204, and user 
display 206. User input 202 receives input from the user 
by any of a variety of ways known to those of ordinary 
skill, such as keypad keys, a touch screen, and the like. 
Input data entered by the user at input 202 is stored at 
display memory 204. User display 206 displays both text 
and graphics and presents data entered at input 202 as 
well as screens created by running applications. 
[0030] External communications circuit 208 provides 
for wireless communication with the network 1 6. (Sche- 
matically-shown antenna 20 is omitted in Figure 3.) 
Complementary to external communication 208, a mo- 
dem 210, indicated in broken lines, could be provided 
for the direct connection of client device 1 21 over stand- 
ard telephone lines. Preferred client device 121 also is 
shown as including a memory 212. Memory 212 is ac- 
cessible by operating system 200. Further, it is contem- 
plated that the client device could have certain limited 
processing resources embodied by processor 214, as 
also shown in broken lines in Figure 3. 
[0031 ] Client device 1 21 also includes the process re- 



ferred to hereinbefore as the "dedicated client" 216. In 
the preferred embodiment, the dedicated client 216 is 
software executed on the client device operating system 
200 to initiate and handle all communications with ded- 

5 icated client server 1 04. Preferably, dedicated client 21 6 
includes an application browser. Those of ordinary skill 
will come to appreciate that, indeed, the only control 
software necessary for the client device 12 is software 
that (i) receives input from input means 202, and per- 

10 haps peripheral devices working with the client device; 
(ii) that controls display 206 and external communica- 
tion circuit 208, and (iii) that both interprets data mes- 
sages received from the server, and generates messag- 
es to send to the server. Dedicated client 216 can be 

15 made to perform all of these functions, and therefore, 
can substitute for any operating system 200 in the client 
device 12. 

[0032] Operating system 200 initiates the dedicated 
client 216 upon instruction from the user of the client 

20 device 12, such as by log-in. Once control has been as- 
sumed by the dedicated client 21 6, our exemplary client 
device 121 initiates communication with a responding 
server 141 (or servers) by sending a message to the 
server indicating that the client would like to open a ses- 

25 sion with the server. To begin communication with a 
server 1 41, the client device 121 can be made to broad- 
cast a signal over network 1 6 to request reply by all serv- 
ers 14A through 14N equipped with dedicated client 
server 104 and supporting data bases 106, 108 (and 

30 112). Then, upon receipt of such a client device signal 
over network 1 6, operating system 1 1 0 in any respond- 
ing server 1 41, or servers, turns over control to dedicated 
server 1 04, which in turn begins communication with the 
requesting client 121. 

35 [0033] A "session" is a logical object that a server 141, 
in a straightforward implementation, might use to track 
a user and the applications being run by that user. The 
message to open a session with the server would in- 
clude the name of the user (user name), the password 

40 of the user, and also some information about the partic- 
ular client device 121 and the dedicated client software 
21 6 that the user is utilizing to access the server. After 
receiving the message, preferably the server 1 41 would 
check to verify that the user name and password includ- 
es ed as part of the message are valid and, if so, to which 
group the user is assigned. Additionally, the server 141 
could use the dedicated client software 21 6 information 
provided in the open-session message to check wheth- 
er there is a more current version, for example, a repos- 

50 itory-stored version, of the dedicated client software 
available for the client device 121 to download. If there 
is a more recent version of the client software 21 6 avail- 
able, server 1 41 could send the client device 121a mes- 
sage indicating which software should be downloaded 

55 by the client device, and where that software is located, 
so that the client device can download and install the 
updated dedicated client software, in accordance with 
information provided in the message from the server. 
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Client device 1 21 then could be made to update its ded- 
icated client control software 21 6 accordingly. 
[0034] Next, assuming that the user name and pass- 
word provided by the client device in the open-session 
message 19 are valid, we see that the server 141 will 
reply to the client with application list data, i.e., an ap- 
plication list message. As mentioned previously, the ap- 
plication list message data gives the client device 121 
the applications that can be run by the user from the 
client device. Preferably, the application list message in- 
cludes session setting information that governs the way 
the client device 121 operates during execution of the 
session. In a straightforward implementation of the con- 
trol-oriented protocol, upon receipt of the application-list 
message, the dedicated client 21 6 causes display of the 
application names included in the list on client display 
206, in any format such as to allow the user of the client 
device to select the dedicated application that the user 
would like to run by way of input 202. 
[0035] Once the client device user has indicated 
which application should be run, the client device 121 
transmits a run application message via external com- 
munication circuit 208 to server 1 41. The run application 
message indicates one application from the previously 
received application list message that is to be accessed 
from data base 1 06 and started by server 1 41 on behalf 
of client device 121. Upon receipt of the run application 
message, server 141 has all of the information neces- 
sary to start an application compliant with the control- 
oriented protocol. From the information already trans- 
ferred to the server in the open session message, server 
141 has information on characteristics of client device 
1 21 , such as the client device's operating system, screen 
size, and microprocessor. 

[0036] Hence, server 141 initializes and starts appli- 
cation 131 by passing all of this client device information 
to the application, and then running the application with 
the command appropriate for the operating system 1 1 0 
of the server. Preferably, the application will be executed 
depending upon the client device information provided 
to it at the time that its execution is started. Thus, it be- 
comes apparent that the source code used to create any 
application 131 preferably includes conditional logic to 
alter the execution of the application, based on param- 
eters of the client device, and also session options that 
are in use when the application is started. Where it is 
preferable that certain applications be started in a con- 
dition "hidden" or otherwise without showing the user 
interface screens of the application on the server, the 
optional administrative server application 1 5 of Figure 1 
could control this manner of execution accordingly. In 
such an execution manner, server 141 would start the 
application while using the command appropriate forthe 
server operating system to open the application, but 
without showing the user interface screens of the appli- 
cation. 

[0037] Once all application initialization steps have 
been completed and the application has been started, 



an initial form message is sent from application 131 to 
client device 121. The initial form message includes all 
data necessary for the client device to draw or otherwise 
create the first screen of the application on the client 

5 device display 206. This includes data necessary to cre- 
ate the user interface controls that are to be shown, and 
the properties of such controls. It will be understood that 
by transmitting all form information messages in this 
way, less data need actually be included in the message 

10 as compared to conventional display protocol methods 
for implementing thin-client systems. Upon receipt of the 
initial form message, client device 1 21 displays a screen 
at display 206 to represent the interface. The initial form 
message communicates how to position and place 

15 screen elements on the client device display 206, or oth- 
erwise represent the running application on the client 
device. 

Control-Oriented Protocol 

20 

[0038] Once the application has started on the server, 
communication between client device 121 and server 1 41 
is restricted to messages descriptive of events. Events 
generally are classified in two categories: User-Control 
25 events and Hardware events. User-Control events oc- 
cur as a result of interaction between a user and the ap- 
plication interface, either on a server or on a client de- 
vice. User events are defined as, but not limited to, the 
activation of certain special keys that may be present 
30 on a client device, and the interaction of the user with 
graphical screen elements on the client device. Exam- 
ples of such special keys are keys on a standardized U. 
S. keyboard such as the ENTER key, the ESCAPE key, 
and the DELETE key. Examples of such interaction 
35 common in windowing environments are button clicks, 
setting of focus from one control to another, freehand 
drawing or writing on a screen, or so designating areas 
of a device or device extension. Other specific examples 
of User-Control events are list-box selection, menu-se- 
40 lection, change of picture image form-close. Other im- 
portant events could fall within the User-Control Events 
category, as will become clear from this disclosure. 
[0039] Hardware events, on the other hand, could be 
triggered by user action, but they also can occur without 
45 user initiation. Hardware events occur on the client de- 
vice. Hardware events are defined but not limited to the 
operation of a client device extension by the user. This 
includes, for example, the triggering of a barcode scan- 
ner, or the swiping of a card through a magnetic card 
50 reader. Also, receipt of input from a client device exten- 
sion such as barcode information read by a barcode 
scanner, or data streams received over a serial COM 
port interface or the like constitute a Hardware Event. 
Further, alerts issued by communications hardware res- 
55 ident on the client device, for example, the loss of the 
communications network signal; and alerts issued by 
the client device itself such as a low memory condition, 
or a low power source condition constitute hardware 
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events. 

[0040] According to the inventive protocol, acknowl- 
edgement of successfully transmitted messages also is 
regarded as an event. Hence, messages transmitted 
from the client device 121 to the application 131 are ac- 
knowledged by the application by transmission of an ac- 
knowledgement message from the application to the cli- 
ent device. 

[0041] All messages are structured with a header sec- 
tion followed by parameters of the message. The mes- 
sage header contains the name of the message which, 
in turn, indicates the type of event to which the message 
relates. The parameters contain variable data specific 
to the associated event. The messages of the control- 
oriented protocol are interpreted at the endpoints of 
communication (the client device or the application on 
the server). At such endpoints, local commands are 
generated to locally perform the action(s) specified by 
received messages. 

[0042] When a Hardware Event or a User-Control 
Event occurs at the client device 121, the client device 
sends a data message to the application 131 to identify 
the event and any accompanying parameters that fur- 
ther specify the event or data that is associated with the 
event. In a preferred implementation in a windowing en- 
vironment, a User-Control event is associated with the 
selection of an item included in a listbox. After the user 
selects an item from a listbox by clicking on a listbox 
control, the client device 1 21 sends a selection message 
indicating that an item has been selected from the list- 
box, along with a parameter indicating which item of the 
listbox has been selected. Upon receipt of the selection 
message, the application 131 interprets the message by 
causing the same action to occur on the server 1 41, and 
correspondingly executing any code associated with the 
event which, in this example, would be the listbox click 
event and/or item selected event. 
[0043] On the other hand, when a User-Control Event 
occurs in the application on the server 141, the applica- 
tion 1 31 processes the event by executing any event pro- 
cedure and associated code linked to the event, and, in 
turn, sends a server event message to the client device 
1 21 to appraise which event occurred, along with param- 
eters indicating any new features of the control user in- 
terface. For example, after the aforementioned listbox 
item has been selected on the application 131, the ap- 
plication preferably transmits a listbox click message to 
the client device 121 to confirm that the listbox was 
clicked, and to provide parameters specifying which 
item was selected by the click, and, where applicable, 
any other status information concerning the listbox. Da- 
ta communicated in the listbox click message, when re- 
ceived by the client device 1 21, generate a new user in- 
terface on the client device at display 206. 
[0044] It is seen that upon receipt of event messages 
from client device 121, application 131 performs the 
processing specified by the commands in the applica- 
tion program Generally, this processing culminates with 



a change to the user interface of the application. Such 
change to the user interface accordingly is transmitted 
from the application 131 to the client device 121. There- 
after, the application 1 31 will once again await input from 

5 the user. When further user input is received, client de- 
vice 121 transmits an appropriate message to the appli- 
cation 131 and the message receipt and acknowledge- 
ment process is started again. Event messages be- 
tween the user device 121 and the running application 

10 131 thus continue in this manner. 

[0045] Now we will compare several dedicated appli- 
cation 131 controls (SDK controls) to corresponding con- 
trols established for commercially available visual de- 
velopment software. Each of these dedicated controls, 

15 when operated by the user at the client device 121, caus- 
es a User-Control Event for which the client device 
sends a message to the running application. In preferred 
embodiments where the Windows NT® and Windows 
CE® operating systems are present on the server 141 

20 and the client device 121 respectively, the dedicated 
controls would appear to the user as nearly identical to 
conventional controls such as those that come with Vis- 
ual Basic® . In this case, the dedicated SDK controls 
essentially will have a counterpart to all of the standard 

25 Windows® controls such as edit boxes, list boxes, but- 
tons, and the like. However, the permissible messages 
representing windowing environment controls are re- 
stricted to describing certain, preselected events. For in- 
stance, edit box controls will transmit updated text in a 

30 message only when they have been made to lose focus. 
The (preselected) transmissible event occurs when the 
user causes the edit box to lose focus. This prevents the 
transmission of messages at each keystroke. List boxes 
will transmit only their selections in messages, but will 

35 not transmit messages indicative of scrolling. Scrolling 
alone will not be considered a significant event which 
justifies message transmission, while list box selection 
does qualify as a transmissible event. So-called combo 
boxes will be made to transmit only when a new value 

40 is selected therein. Scroll bars will be limited to trans- 
mitting their new position, only after scrolling has 
stopped. Scrolling alone will not be regarded as a sig- 
nificant event and so messages representative of mere 
scrolling will not be transmitted between the client and 

45 the running application. Mouse clicks on an input button, 
as mentioned above, will be transmitted as a user-con- 
trol event, but mere mouse movements alone, without 
more, will not be so transmitted. 

[0046] Thus, the inventive control-oriented protocol 
50 responds to user controls by transmitting messages in- 
dicative of only selected significant events from all oc- 
currences that would be transmitted from the client de- 
vice to the server in a display-oriented protocol. In the 
disclosed control-oriented protocol, all occurrences of 
55 user action are considered as event candidates for the 
generation of messages in the control-oriented protocol. 
However, generally only those user action occurrences 
that are necessary for the execution of the application 
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will be selected as events to be made the subject of per- 
missible messages. 

[0047] To illustrate the restriction of message-trans- 
missible events from among all user action occurrences 
that are transmitted from client to server under display- 
based protocols, we further consider the mouse control. 
In a display-based protocol, the user's movement of the 
mouse (without more) on a client device would be an 
operation for which a mouse movement message would 
be sent to the running application. Thereafter, the appli- 
cation would transmit a reply message to the client de- 
vice to represent the mouse movement on the client in- 
terface. In the present control-oriented protocol by con- 
trast, mere mouse movements are not selected events 
for which messages are generated at the client device 
and sent to the application. Preferably, the dedicated cli- 
ent software 216 will display the mouse movement on 
the client display 206, but mouse movement data will 
not be transmitted to the running application. Only when 
the mouse has been positioned over a control presented 
on the application interface and clicked would a Us- 
er-Control Event message be generated at the client de- 
vice and transmitted to the application. The user's op- 
eration of the control by mouse click constitutes a Us- 
er-Control Eventforwhich a message must be transmit- 
ted to the application for processing on the server (ap- 
plication) side. 

[0048] By so generally limiting messages communi- 
cated between the running application 1 31 and the client 
device 121 to selected events, the control-oriented pro- 
tocol thus restricts the amount of data passed between 
the client device and the server. The protocol is contem- 
plated as allowing the communication of messages in- 
dicative of User-Control Events including clicking-on a 
button, a list-box selection, a menu-selection, neces- 
sary changes of picture image, form-closing, and other 
events necessary in running a given application. How- 
ever, the preferred control-oriented protocol limits trans- 
mitted information to only that necessary to provide ex- 
ecution of the running application. In this way, the con- 
trol-oriented protocol of the present invention vastly dif- 
fers from conventional display-oriented protocols where 
all user events, such as mouse movement messages, 
and advancing of a cursor message, are transmitted be- 
tween the thin-client and its server. The preferred pro- 
tocol of the invention involves generation, transmission 
and interpretation of only carefully selected events to 
thereby accommodate the relatively low band-width 
characteristics of RF (wireless) networks. 
[0049] As described hereinbefore, the preferred pro- 
tocol is not limited to User-Control Events, but also in- 
cludes distinct "Hardware Events" that occur atthe client 
device. Preferably, the protocol generates, interprets 
and provides transmission for data messages repre- 
senting important alert conditions including low memory 
or low battery at the client device, and also hardware 
events such as receipt of input from a scanner, or serial 
data input at the client device. Hardware events, of 



course, also can be triggered by user action, such as 
when the user connects a bar code scanner as input to 
the user's thin-client device. 

[0050] Again, a preferred implementation wherein the 

5 server operating system 110 comprises Windows NT® 
and the client device operating system 200 comprises 
Windows CE®will be considered. In such an exemplary 
implementation, all control descriptions would be en- 
coded using WIN32® application program interface 

10 (API) parameters for the creation of a window. All mes- 
sages would use WIN32® data messages. It is recog- 
nized that both of these operating systems use WIN32® 
parameters, and therefore no translations would be nec- 
essary. In this implementation, then, data representative 

15 of controls and messages can be used directly by the 
running dedicated application. For instance, where the 
user presses a button on the client device 1 21, data rep- 
resenting the control sent to server 141 would include 
merely the window handle for the button and the 

20 WN_CLICK message. Then, when server 141 receives 
this control message, it has only to post a WN_ CLICK 
message with the particular handle on the message 
queue for the running application 1 31 . Any further con- 
trol processing would be handled by the server side op- 

25 erating system 

[0051] Also, in the preferred implementation of sys- 
tem 1 0, any software control can be used in a dedicated 
application, however, only dedicated controls will be 
made visible to the user on display 206. Conversely, it 

30 is contemplated that all applications created using ded- 
icated controls will behave exactly like conventionally- 
created applications with conventional controls when 
such applications are run outside of dedicated server 
104. 

35 [0052] It also has been recognized, for example, that 
Windows® message boxes are modal. They will act to 
halt a running application until acontrol button is clicked. 
However, where message boxes are pre-defined dia- 
logue boxes that do not make use of controls sent and 

40 received between server 141 and client 121, such mes- 
sage boxes would not be displayed by the client and, 
therefore, could not be answered by the user. This would 
freeze the application. For this reason, server 141 and 
dedicated client 121 preferably are contemplated as 

45 transmitting their own message boxes under the control- 
oriented protocol. Such message boxes behave like 
conventional message boxes, exceptthey are displayed 
by the client device 121 at display 206. When the user 
answers such a message box, the client device 12 

50 sends the user's answer backto the running application, 
again , in the form of an event rather than a return value. 
A message box call in accordance with this exemplary 
embodiment requires one additional parameter over 
those of Windows® . The additional parameter is an 

55 identification that is passed back to the application in 
the message box answer event, in order to help identify 
the specific message that the user has answered. 
[0053] A special message is generated when the user 
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of the client device seeks to close the application in use. 
Here, the user causes a request to close the application 
131 to be sent from the client device 121 to the applica- 
tion. Unlike all other messages in the control-oriented 
protocol, the client device 121 does not execute the ac- 
tion specified by this message, before transmitting the 
message. Because the application is running on the 
server 141, any indication that the application has been 
closed is made to come from the server. Upon receipt 
of a request to close message (or when action is taken 
by the server on its own to close an application), server 
141 executes any code associated with the termination 
of the application, and checks whether such code re- 
quires interruption or cancellation of the closing. If there 
is no interruption or cancellation, application 131 trans- 
mits a close application message to the client device 121 
and subsequently terminates. Preferably, upon receipt 
of a close application message from the application, the 
client device 121 destroys all references to the applica- 
tion and closes the application on the client device. 

Operation 

[0054] Figures 4A and 4B show a flowchart for oper- 
ation of system 10. In step S-10, the client device 121 
initiates a session by sending an open session message 
to server 141. Step S-10 is could comprise a separate 
step of broadcasting a message over network 16 in 
search of all servers 14A through 14N that are associ- 
ated with system 1 0, by virtue of their inclusion of a ded- 
icated server 104. In this way, each client device 12A 
through 12M can search for all member servers 14A 
through 14N that recognize a broadcast request signal 
from any member client device 121. 
[0055] In step S-12, server 1 41 receives the open ses- 
sion message and registers the name of the user (user 
name), the password of the user, and appropriate infor- 
mation about the client device 121 and its dedicated cli- 
ent software 21 6. In step S-12, server 141 also confirms 
that the user name and password included as part of the 
open session message are valid and, if so, to which 
group the user is assigned. Next, in step S-14, server 
141 determines, based upon information provided in the 
open session message, whether there is a more current 
version, for example, a repository-stored version, of the 
dedicated client software available for the client device 
to download. If there is a more recent version of client 
software available, in step S-1 6 server 1 41 sends to the 
client device 121, message data representative of which 
software should be downloaded by the client device, 
and where that software is located. In step S-1 8, client 
device 121 downloads and installs updated dedicated 
client software 21 6 in accordance with the message da- 
ta from server 141. 

[0056] If no software upgrade is necessary, or if up- 
grading has been completed, advance is made to step 
S-20 where server 141 replies to the client 121 with the 
application list message. The application list data iden- 



tifies for the client device 1 21, the applications that can 
be run by the user from the client device. Preferably, it 
also includes session setting information that governs 
the way the client device 1 21 will operate during the ses- 
5 sion. Applications authorized for use by the user can be 
displayed by title, icon or the like at display 206 in step 
S-20, whereupon the user enters a chosen application 
from the list at input 202. 

[0057] Once the user of the client device has decided 
10 which application should be run, the user causes the cli- 
ent device 121 to transmit a run application message to 
server 1 41 in step S-22. Upon receipt of the run applica- 
tion message, server 141 will have all of the information 
necessary to start a dedicated application. This includes 
15 parameters of the client device 121 that will remotely 
interact with the selected application, such as the client 
device's operating system, screen-size, and microproc- 
essor, which parameter information already was trans- 
ferred to the server with the open session message in 
20 step S-10. In step S-24, the server 141 initializes and 
starts selected application 131 by passing to the appli- 
cation all of the parameter information about the client 
device 121, and then running the application with a com- 
mand appropriate for operating system 1 1 0 on the serv- 
es er 141. 

[0058] Once all the aforementioned application initial- 
ization steps have been completed and the application 
has been started, an initial form data message is sent 
from running application 131 to the client device 121 in 
30 step S-26. The initial form message includes all infor- 
mation necessary for the client device to draw or other- 
wise create the first screen of the application on the cli- 
ent device display 206, including necessary dedicated 
controls. Upon receipt of the initial form message, client 
35 device 121 displays a screen representing the interface 
with controls for the application running on the server, 
on client display 206, in step S-28. The initial form mes- 
sage information is all that is necessary to position and 
place all screen elements on the client device display 
40 206 (or otherwise initiate a representation of the appli- 
cation on the client device). In this way, the application 
which began running on the server 141 in step S-26 is 
mimicked at the client device 12 display 206 in realtime. 
[0059] Figure 4B continues the flow chart of Figure 4A 
45 and illustrates how the interaction between the client de- 
vice 121 and the application 131 takes place once the 
application is running on the server 141. Once applica- 
tion 131 has started, communication between client de- 
vice 121 and server 141 is based on occurrences select- 
50 ed as User-Control Events and Hardware Events. 

[0060] In the absence of any event, the dedicated cli- 
ent 21 6 simply remains in a waiting mode, pending ac- 
tion by the user or some other reportable event. When 
it is determined that a Hardware Event or a User-Control 
55 Event occurs on the client device 121 as depicted in step 
S-30, client device 121 sends an event message to the 
application 1 31 in step S-32 to indicate which event oc- 
curred, and to provide any accompanying parameters 
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that further specify the event or the data that is associ- 
ated with the event. Previously, a User-Control Event, 
such as the user's selection of an item from a listbox 
was discussed as the User-Control Event. In this case, 
the client device 121 sends a selection message (step 5 
S-32) indicating that an item had been selected from the 
listbox, including a parameter indicating which item of 
the listbox has been selected. Thereafter, control re- 
turns to step S-30. 

[0061] Next, under routine operation, another event 10 
will not occur on the client side and advance will be 
made to step S-34 where a corresponding User-Control 
Event occurs in the application on the serverside. Here, 
the application 131 processes the client-side initiated 
event by executing any event procedure and associated 15 
code linked to the event, and then sends a server event 
message to the client device 1 21 in step S-36 to describe 
the corresponding server side event which occurred, 
and to provide data indicative of any new features nec- 
essary for the control user interface on the client device. 20 
If we continue the listbox example, if the listbox item 
were selected on the application, the application would 
transmit a listbox-click message back to the client de- 
vice to indicate that the listbox was clicked, and to pro- 
vide data specifying which item was selected by the click 25 
event. 

[0062] It should be understood that step S-36 could, 
itself, comprise multiple steps. For instance, where no 
display screen change is warranted as a result of the 
server-side event in step S-36, process control simply 30 
returns to step S-30 wherein the dedicated client 216 
awaits a next control operation activity. On the other 
hand, if, in step S-36 the corresponding event on the 
server-side necessitates a change in the presented user 
interface, this will be carried out by the application's pro- 35 
vision of a new user interface data message to the client 
device 121. In response to receipt of such updating in- 
terface data message, dedicated client 21 6 will change 
the screen at display 206 to mimic the application as it 
appears on server 141. Thereafter, again process control 40 
will return to step S-30 to await a next activity by the 
user. Control flow continues in the manner depicted in 
Figure 5B until the application terminates or is changed. 
[0063] Later, when it is determined that the user re- 
quests that the application currently in use be closed in 45 
step S-38, a request to close the application 1 31 is sent 
from the client device 121 to the application in step S- 
40. In the preferred system 1 0, client device 121 cannot 
execute the action specified by the closure message be- 
fore transmitting this message. All indications that the 50 
application has been closed must come from the server 
141. Thus, from the client device 121, the user can do no 
more than transmit a request to close the application at 
step S-40. When the request to close is received by the 
application 131, server 141 executes any code necessary 55 
for termination of the application, and checks whether 
such code requires interruption or cancellation of the 
closing. This is subsumed in decision step S-42. If there 



is no such interruption, the application 131 transmits a 
close application message to the client device 121 in 
step S-44 and subsequently terminates. Upon receipt of 
a close application message from the application on the 
server, client device 121 destroys all references to the 
application and thus closes the application thereon. 

Dedicated Client Installation 

[0064] Figure 5 is a process chart illustrating how a 
client device 1 21 in any configuration remotely can install 
and upgrade dedicated client software (dedicated cli- 
ent). Client device 121 issues a request to install dedi- 
cated client software 216 to the server 141. Server 141 
replies with an acknowledgement that the message re- 
questing installation information has been received. 
Server 1 41 itself is equipped with a repository of updated 
client software, or the server at least has access to a 
remotely stored repository of such software and also in- 
formation indicating the version of the client software to 
be downloaded to client device 121. It is contemplated 
that the repository version of such software can be com- 
pared to the version of the client software in use at client 
device 121. If an appropriate repository version of client 
software is found by the server 1 41, it sends a message 
indicating what new version data should be downloaded 
by the client device 1 01 2, and the location of the data. 
The client device 1 01 2 acknowledges this data by send- 
ing an acknowledgement message to the server. Once 
the client device 1012 receives this message, it down- 
loads the necessary files from server 141, as indicated 
in the downloaded message and installs the files. 

Exemplary Dedicated Application 

[0065] Figure 6 illustrates an arbitrary dedicated ap- 
plication 131. In the contemplated commercial embodi- 
ment, the application 131 would be developed in a high 
level, graphical environment (language) such as Visual 
Basic® , Delphi™, Visual J++® , J-Builder™, C++ Build- 
er™, Visual C++® and Power Builder® or other such 
language with which those of ordinary skill are familiar. 
All such applications are compiled forthe operating sys- 
tem 110 of the server 141, and run on the server operat- 
ing system. However, their graphics interface with the 
user, of course, is accessed by the operating system 
200 of the client device 12. At the client-side, the user 
can launch new dedicated applications and switch be- 
tween dedicated applications that are running. Applica- 
tion 300 can be created as well as run on system 1 0. At 
the time that the source code for application 300 is gen- 
erated, the application is made to comply with the pre- 
ferred control-oriented protocol. 

[0066] As seen from Figure 6, each dedicated appli- 
cation stored in data base 106 includes a directory of 
controls 302 that comply with the control-oriented pro- 
tocol, and a form wrapper 304 which includes event han- 
dlers 306 that regulate communication between the 
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dedicated application and the server, as described su- 
pra. 

[0067] The form wrapper 304 initializes by passing it 
a reference to any regular form in the visual develop- 
ment language (e.g., Visual Basic®). Form wrapper 
304 then assumes control over the communication de- 
tails in any form. Any form from a conventional visual 
development software that is going to be used with sys- 
tem 10 must initialize a form wrapper as a load event, 
and thereafter destroy the form as an unload event. The 
running application 131 calls up internal event handler 
306 to record all control operations made at the client 
device 12. Preferably, event handlers for input will pro- 
vide a time stamp of each event, receive the specific 
event data, and record the type of input data. Event han- 
dlers for output likewise will provide a time stamp and a 
status indication of whether the requested function suc- 
ceeded. In the case of a print command, for example, 
the output event handler would indicate whether or not 
data for which a print request was made, actually was 
successfully printed. Event handlers 306 also attend to 
all special occurrences (Hardware Events) such as 
communication errors, message box responses, and 
low battery indications and low memory indications, as 
well as other special events appreciated by those of or- 
dinary skill in the art. In the preferred embodiment, the 
event handlers also can be made responsible for pro- 
viding a hibernate message to the running application 
when the dedicated client 21 6 detects that the client de- 
vice is low on memory power. When the running appli- 
cation 131 receives a hibernate message, it will initiate 
a shutdown or take other pertinent action to prevent the 
loss of data. As to communication errors, the event han- 
dlers are responsible for advising the running applica- 
tion thereof so that the application properly can attend 
to the error. 

Alternative Embodiment 

[0068] Figure 7 is similarto Figure 3 in showing details 
of an alternative embodiment of the invention. Here, the 
application 10131 is shown as running on aserver 10141. 
The application 10131 includes user interface program- 
ming controls 1 302 and hardware programming controls 
1304 which, in turn, interface with a communications 
layer 1306 that transmits messages in accordance with 
the control-oriented protocol of the present invention. 
The client device 10121 likewise is equipped with (ded- 
icated) client software 1 21 6 that transmits and receives 
messages contained in the control-oriented protocol. In 
the embodiment, when user-interface control messages 
are received, client software 1 21 6 similarly controls dis- 
play 1 206 of the client device 1 01 2 to present a proper 
user interface from the application 10131. On the other 
hand, when hardware control messages are received at 
client device 10121, the client software 121 6 communi- 
cates with an abstract hardware layer 1218 to control 
the input and output hardware of physical hardware pe- 



ripherals 1220 that are depicted as part of, or connected 
to the client device 1 0121. 

[0069] Conversely, in response to input from the user 
at the client user display 1206, client software 1216 
5 transmits user control messages to the application 
1 0131 to notify the application of such input from the us- 
er. In response to input from the input/output hardware 
peripherals 1220, the client software 1216 transmits 
hardware control messages to the application 10131 
10 likewise to notify the application of the input received 
from the user. Here, preferably, the application 10131 in- 
terprets the control-oriented protocol messages through 
a control-oriented protocol communications layer 1306 
and processes the input through event procedures pro- 
fs grammed by the developer of the application with the 
user interface programming controls 1 302 and the hard- 
ware programming controls 1304. 

Exemplary Screen Displays 
20 " 

[0070] The flow charts of Figures 4A and 4B and their 
corresponding description set out in detail the opening 
and use of a dedicated application in accordance with 
the present invention. Next, exemplary screen displays 

25 are presented for detailing the creation and operation of 
a new application project in accordance with the inven- 
tion. These exemplary screen displays were created us- 
ing Visual Basic® run on the Windows NT® and Win- 
dows CE® operating systems discussed infra. Figure 8 

30 shows a screen display wherein a development project 
has been initiated to create a new application. Features 
of the new application are boxes for entering "Price" and 
"Qty" (quantity) data. The application will calculate the 
total for the user. Following registration of the new ap- 

35 plication in a server, the new application may be run on 
the server as illustrated in Figure 9. Figure 10, in turn, 
shows operating system 200 of client device 1 2 mimick- 
ing the running application on display 206. 
[0071] In the preferred embodiment, all applications 

40 dedicated for system 1 0 would be de-bugged in a con- 
ventional manner. It is contemplated that de-bugging 
would be commenced in a manner similar to regular 
conventionally-created applications, such as those cre- 
ated in Visual Basic® . In addition, the dedicated appli- 

45 cation can be de-bugged while being displayed at the 
client-side device 12. All conventional de-bugging tools 
are to be made available while running a dedicated ap- 
plication. 

[0072] It is to be understood that there can be various 
50 changes and/or modifications to the preferred embodi- 
ments of the present invention disclosed herein. These 
changes and/or modifications may be made by one of 
ordinary skill in the art. However, all such changes and/ 
or modifications still would result in an arrangement well 
55 within the scope of the invention as set forth in the 
claims. 
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Claims 

1. A thin-client system operative over a communica- 
tions network, said system comprising: 

a server computer including a communication 
control device for sending and receiving mes- 
sages over the network and an operating sys- 
tem, said server having access to a data base 
capable of storing dedicated applications ded- 
icated to said system and executable by said 
operating system; and 

at least one client device including display 
means, an external communication device for 
sending to and receiving messages from said 
server computer over said network, and dedi- 
cated client means for controlling said display 
means and said external communication de- 
vice, said dedicated client means interpreting 
messages received from said server computer 
and generating messages recognizable by said 
server, said messages sent between said serv- 
er computer and said client device conforming 
to a control-oriented protocol that restricts mes- 
sage communication to only messages de- 
scribing certain preselected events. 

2. A thin-client system as claimed in claim 1 , wherein 

said preselected events include user control 
events caused by user action at said client de- 
vice, each of said user control events being rec- 
ognizable by a dedicated application running 
on said server as indicative of a certain control 
of said running application that is associated 
with said one of said preselected events and 
that is operable by a user at said client device 
to control said running application, and wherein 
a message from said client device to said serv- 
er includes data representative of said one 
preselected event and excludes data repre- 
sentative of other user action performed in op- 
eration of said associated application control 
but not representative of said one event. 

3. A thin-client system as claimed in claim 2, wherein 
said preselected events further include hardware 
events caused by user action at said client device 
and hardware events caused by conditions at said 
client device. 

4. A thin-client system as claimed in claim 3, wherein 
said control-oriented protocol is overlaid on a stand- 
ard wireless communication protocol. 

5. A thin-client system as claimed in claim 3, compris- 
ing plural communication networks, plural server 
computers and plural client devices. 



6. A thin-client system as claimed in claim 3, wherein 
said control-oriented protocol restricts message 
communication in windowing environments such 
that 

5 

for edit boxes, loss of focus constitutes a sig- 
nificant event, whereby messages represent- 
ing edit boxes will be transmitted only when 
such edit boxes have been made to lose focus; 
10 for list boxes, selection from such a list box con- 

stitutes a significant event, whereby messages 
representing list boxes will be transmitted only 
when a selection from such a list box has been 
made and messages indicative of scrolling will 
15 not be transmitted; 

for combo boxes, selection of a new value con- 
stitutes a significant event, whereby messages 
representing combo boxes will be transmitted 
only when a new value has been selected; 
20 for scroll bars, arrival at a new scroll bar posi- 

tion after scrolling has stopped constitutes a 
significant event, whereby messages repre- 
senting scroll bar movement will be transmitted 
only after scrolling has stopped at a new scroll 
25 bar position; and 

for mouse button clicks, a button click on such 
a mouse constitutes a significant event, where- 
by only mouse button clicks will be transmitted 
and messages indicative of mere mouse move- 
30 ments alone will not be transmitted. 

7. A method of communication between a thin-client 
device and a server computer over a communica- 
tion network for interfacing said client device with 

35 an application executable on said server, said meth- 
od comprising the steps of 

at said client device, generating a message de- 
scriptive of a preselected event recognizable by 
40 said application as indicative of a certain appli- 

cation control that is associated with said 
preselected event and that is operable by a us- 
er at said client device, 

said message generating step including the 
45 steps of including data representative of said 

preselected event and excluding data repre- 
sentative of user action performed in operation 
of said associated application control but not 
representative of said preselected event; and 
50 at said client device, transmitting said message 

generated in said generating step over said net- 
work to said server. 

8. A method as claimed in claim 7, further comprising 
55 the steps of, at said application, 

receiving said message transmitted by said cli- 
ent device during said transmitting step, 
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interpreting data received in said message and 
representative of said preselected event in or- 
der to recognize said application control asso- 
ciated with said preselected event; 
generating an acknowledgement message de- 
scriptive of an acknowledgement event at said 
application; and 

transmitting said acknowledgement message 
over said network to said client device. 

9. A method as claimed in claim 8, further comprising 
the steps of, at said application, determining wheth- 
er said application control recognized in said inter- 
preting step necessitates a change in a user inter- 
face created by said application, and 

in a case where said application control neces- 
sitates a change in said user interface, gener- 
ating a message descriptive of a change user 
interface event recognizable by said client de- 
vice as indicative of an updated user interface 
and creating said updated user interface at said 
application; and 

transmitting said change user interface mes- 
sage to said client device whereupon said client 
device interprets said transmitted change user 
interface message to recognize how a corre- 
sponding user interface presented at said client 
device should be changed to correspond to 
said update user interface created at said ap- 
plication. 

10. A method as claimed in claim 9, further comprising 
the steps of, at said client device, 

generating a message descriptive of a Hard- 
ware event recognizable by said application as 
indicative of a certain condition at said client de- 
vice, each Hardware event being recognizable 
by said application as an event either caused 
by user action or caused by said client device 
without user action; and 
transmitting said messages descriptive of 
Hardware events over said network to said ap- 
plication. 

11. A method as claimed in claim 10, further comprising 
the steps of, at said server, 

executing applications that include windowing 
environment application controls with each 
control associated with a preselected event for 
execution on said server in accordance with 
messages sent by said client device. 

12. A method as claimed in claim 11, wherein in said 
steps of executing applications with windowing en- 
vironment controls further comprises the steps of: 



for edit boxes, selecting as a significant event, 
a loss of focus whereby messages represent- 
ing edit boxes will be transmitted only when 
such edit boxes have been made to lose focus; 
5 for list boxes, selecting as a significant event, 

a selection from such a list box whereby mes- 
sages representing list boxes will be transmit- 
ted only when a selection from such a list box 
has been made and messages indicative of 
10 scrolling will not be transmitted; 

for combo boxes, selecting as a significant 
event, a selection of a new value whereby mes- 
sages representing combo boxes will be trans- 
mitted only when a new value has been select- 
's ed; 

for scroll bars, selecting as a significant event, 
a new scroll bar position after scrolling has 
stopped whereby messages representing 
scroll bar movement will be transmitted only af- 
20 ter scrolling has stopped at a new scroll bar po- 

sition; and 

for mouse button clicks, selecting as a signifi- 
cant event, a button click on such a mouse 
whereby only mouse button clicks will be trans- 
25 mitted and messages indicative of mere mouse 

movements alone will not be transmitted. 

13. Amethod as claimed in claim 10, further comprising 
the steps of: 

30 

at said client device, generating and transmit- 
ting an open session message over said net- 
work to initiate communication with a server, 
said open session message including a user 
35 name, a user password and data descriptive of 

parameters of said client device; 
at said server, upon receipt of said open ses- 
sion message, verifying said user name and 
password, and comparing said descriptive data 
40 representative of said client device parameters 

with current versions of software available for 
said client device to determine whether said 
current software versions should be download- 
ed to said client device, and thereafter identify- 
45 jng said client device software to be download- 

ed in a case where it is determined that said 
current software should be downloaded; and 
at said server, generating and transmitting an 
application list message to said client device, 
50 said application list message including session 

setting data for regulating operation of said cli- 
ent device during a session. 

14. Amethod as claimed in claim 13, further comprising 
55 the steps of: 

at said client device, receiving and interpreting 
said application list message in order to create 
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a user interface allowing a user to select an ap- 
plication for execution on said server; 
at said client device, generating a run applica- 
tion message descriptive of an application cho- 
sen event recognizable by said server as indie- 5 
ative of a user control operated to select said 
application for execution, and transmitting said 
run application message over said network to 
said server; 

at said server, receiving and interpreting said 10 
run application message, starting execution of 
the application selected, and providing said ap- 
plication with client device parameter data re- 
ceived from said client device in said open ses- 
sion message; 15 
at said application, generating an initial form 
message and transmitting said initial form mes- 
sage to said client device; and 
at said client device, receiving and interpreting 
said initial form message, and creating a user 20 
interface including application controls in re- 
sponse to receipt of said initial form message. 

15. A method as claimed in claim 14, furthercomprising 

the steps of: 25 

at said client device, generating a close appli- 
cation request message requesting closing of 
an application executing on said server and 
transmitting said request message to said serv- 30 
er; 

at said server, determining the presence or ab- 
sence of conditions interrupting or canceling 
closure of said executing application, and clos- 
ing said executing application in the absence 35 
of such conditions; and 

at said server, generating an application closed 
message and transmitting said application 
closed message to said client device. 

40 

16. A method as claimed in claim 15, furthercomprising 
the steps of 

communicating over plural networks including 

at least one wireless communication network; 45 

and 

communicating between plural thin-client de- 
vices and plural applications on plural server 
computers. 

50 

17. A computer-readable medium having computer-ex- 
ecutable instructions for performing the steps of any 
of claims 7 through 15. 

18. A method of providing communication between a 55 
thin-client device and a server computer over a 
communication network for interfacing said client 
device with an application executable on said serv- 



er, said method comprising the steps of 

selecting as a significant event, from among all 
actions performed by a user at said client de- 
vice in operating a certain application control, 
an action necessary for said application to re- 
spond to the user's operation of said application 
control; and 

restricting communication of the user's actions 
in operating said application control to messag- 
es transmitted from said client device to said 
server, descriptive of said significant event. 

19. Amethod as claimed in claim 18, furthercomprising 
the steps of: 

selecting as significant events, acknowledge- 
ments of messages received, changes in user 
interface, Hardware events occurring at said 
client device, open session requests, list appli- 
cation requests, and close application re- 
quests. 

20. Amethod as claimed in claim 19, furthercomprising 
the steps of: 

communicating over plural networks including 
at least one wireless communication network; 
and 

communicating between plural thin-client de- 
vices and plural applications on plural server 
computers. 

21. A method as claimed in claim 19, wherein, in win- 
dowing environments, said method further compris- 
es the steps of: 

for edit boxes, selecting as a significant event, 
a loss of focus whereby messages represent- 
ing edit boxes will be transmitted only when 
such edit boxes have been made to lose focus; 
for list boxes, selecting as a significant event, 
a selection from such a list box whereby mes- 
sages representing list boxes will be transmit- 
ted only when a selection from such a list box 
has been made and messages indicative of 
scrolling will not be transmitted; 
for combo boxes, selecting as a significant 
event, a selection of a new value whereby mes- 
sages representing combo boxes will be trans- 
mitted only when a new value has been select- 
ed; 

for scroll bars, selecting as a significant event, 
a new scroll bar position after scrolling has 
stopped whereby messages representing 
scroll bar movement will be transmitted only af- 
ter scrolling has stopped at a new scroll bar po- 
sition; and 
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for mouse button clicks, selecting as a signifi- 
cant event, a button click on such a mouse 
whereby only mouse button clicks will be trans- 
mitted and messages indicative of mere mouse 
movements alone will not be transmitted. 5 



22. A computer-readable medium having computer-ex- 
ecutable instructions for performing the steps of any 
of claim 18 through 21 . 
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